I have no idea or not if this will help.
I have a similar problem on my laptop that has sbc/home-portal software for my DSL.
Sounds to me like your licenses are not installing properly automatically.
Basically there is something on your computer that prevents Houdini from directly generating the keys.
In programs->sidefx there is the ability to launch the “license administrator” independently.
In here you can see under the “installed licenses” if you have any valid licenses installed.
If you don't see anything in that tab, then they aren't installed.
If there is nothing there are you immediately screwed?
Maybe not.
As longs as you have account to generate them on the sidefx web page.
http://service.sidefx.com [service.sidefx.com]
you can enter them manually.
On this page you can log in and generate your “keys”,
and then use the stand-alone license administrator to enter them manually.
file(pull down menu)–>manually enter keys.
the sidefx page may ask you for your “system/machine code” which you can get from the license administrator by
view(pulldown menu)—> diagnostic information.
there is also info on the previously mention sidefx page to walk you through it.
This will work for commercial licenses, for “apprentice licenses” I'm not sure.
hope that helps
Jim
Found 60 posts.
Search results Show results as topic list.
Technical Discussion » Houdini error. Help Please
- Jim Ellis 2001
- 60 posts
- Offline
Technical Discussion » copy stamp the L-system rules (turtle randomizing)?
- Jim Ellis 2001
- 60 posts
- Offline
Yeah I was afraid that the Copy sop didn't use strings,
but it was funny because I didn't get an error flag in either the “Copy” or the “Lystem”…
and with either of those, you cant just click next to the parameter value and see your input/output data.
But what both you guys suggested works wonderfully!
Thanks so much!
Antoine's seems to be exactly what I'm after…
and sick/amazing things are starting to happen.
but it was funny because I didn't get an error flag in either the “Copy” or the “Lystem”…
and with either of those, you cant just click next to the parameter value and see your input/output data.
But what both you guys suggested works wonderfully!
Thanks so much!
Antoine's seems to be exactly what I'm after…
and sick/amazing things are starting to happen.
Technical Discussion » copy stamp the L-system rules (turtle randomizing)?
- Jim Ellis 2001
- 60 posts
- Offline
Hey there,
This might be a silly question
It looks as if variables (for “Stamping”) from a copy sop can't be used in the “rules” of an L-system.
can they?
I would love to be able to randomize my copies of an l-system on a template geometry on a “turtle/rule” level.
No problem “stamping” things like “generations”.
Doesn't look like it can be done to the “rules” though.
Thanks
Jim Ellis
This might be a silly question
It looks as if variables (for “Stamping”) from a copy sop can't be used in the “rules” of an L-system.
can they?
I would love to be able to randomize my copies of an l-system on a template geometry on a “turtle/rule” level.
No problem “stamping” things like “generations”.
Doesn't look like it can be done to the “rules” though.
Thanks
Jim Ellis
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
Thanks for the tip Simon!
I'm going to chase this a bit more soon.
I'll post any of my findings here for anyone who might be interested.
Maybe even add some “user comments” in the help.
I also welcome/encourage anyone else playing around in this area,
to write their findings here.
I'm going to chase this a bit more soon.
I'll post any of my findings here for anyone who might be interested.
Maybe even add some “user comments” in the help.
I also welcome/encourage anyone else playing around in this area,
to write their findings here.
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
Yeah I am probably trying to “push it too much”.
The “clean” sop doesn't really seem to help very much on each step of the cookie.
I'll have to give it closer inspection.
“As far as ”Jitter“ not helping,”
what I meant was that in certain cases you actually have to upstream and change jitter in previous cookies to make later cookies work.
“what is the end result I'm trying to achieve?”
Well, as far what has been happen happening here with this last example,
simply a test to try to stabilizing animated cookies and find out any limitations/rules,
so that the boundaries of the process are somewhat defined.
What I'm trying to achieve overall is:
1) Stable intuitive animateable sculpting tools that can be additive or subtractive,
that can use a wide variety of shapes.
Meta is nice as well, as well as the “brush/sculpt” tools but cookies have the potential to get the job done better.
Sort of like having a block of marble that you chip away at to create a piece of sculpture.
Now if each one of those “chips” can be animated and controlled procedurally,
then creative possibilities come rushing in.
Add to that the fact that animated “unions” can be done as well…
2) Recursion (aside from being a time saver) is great because with slight variation of a simple set of rules (placement, offset through time, etc.) you can get some very wild effects. Some natural looking, some other worldly. All done with objects that the user has visual feedback with throughout each step of the creation.
The “clean” sop doesn't really seem to help very much on each step of the cookie.
I'll have to give it closer inspection.
“As far as ”Jitter“ not helping,”
what I meant was that in certain cases you actually have to upstream and change jitter in previous cookies to make later cookies work.
“what is the end result I'm trying to achieve?”
Well, as far what has been happen happening here with this last example,
simply a test to try to stabilizing animated cookies and find out any limitations/rules,
so that the boundaries of the process are somewhat defined.
What I'm trying to achieve overall is:
1) Stable intuitive animateable sculpting tools that can be additive or subtractive,
that can use a wide variety of shapes.
Meta is nice as well, as well as the “brush/sculpt” tools but cookies have the potential to get the job done better.
Sort of like having a block of marble that you chip away at to create a piece of sculpture.
Now if each one of those “chips” can be animated and controlled procedurally,
then creative possibilities come rushing in.
Add to that the fact that animated “unions” can be done as well…
2) Recursion (aside from being a time saver) is great because with slight variation of a simple set of rules (placement, offset through time, etc.) you can get some very wild effects. Some natural looking, some other worldly. All done with objects that the user has visual feedback with throughout each step of the creation.
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
Nice!
Your use of the “connectivity” sop and “primitive split” sop was nicely done.
The “connectivity” (created “class” attribute) will certainly make grouping a lot easier as well.
I just had the point colors just thrown in there for display purposes.
As far as rendering out the .bgeo files…
you're right, it doesn't make any difference.
Perhaps it was my constant tweaking evoking imaginative distortion. ops:
My attempts with subdivision was just a quick dirty means at trying to smooth out the geometry from the “consolidate edges” in the cookie.
Your solution of the “Primitive split” seems also to take care of the rough edges created by the “consolidate edges” of the “cookie”.
I've added a new version of the file.
All new sops have been colored light purple.
There is a “switch” near the bottom of the chain to move between the stable version (Switch setting 0) of the scene,
and another version (Switch setting 1) with a new problems.
Switch 0:
I added another stationary sphere (non-intersecting for a total of 2 spheres) into a “merge”.
The merge is then wired into the first input of cookie1.
The second input of cookie1 is the same as before, 5 animated non-intersecting spheres.
So now both inputs have multiple non-intersecting objects in them.
I thought I had the makings of a “rule” here with working with animated cookies.
You can have as many sources placed into a “merge” for either input,
as long as sources inside a merge do not intersect.
Even with consolidated edges,
you still need to avoid having the source geometry of the merge “intersect” in any way.
Then I complicated things, and this rule started to break down.
Switch 1:
This takes the output of cookie2, creates two copies of it.
One copy is rotated, scaled and translated, so it sits slightly above and in front of the original copy.
A new cookies is pulled (cookie3) as an “A minus B”.
It immediately appears that no amount of “jitter” (on cookie3) can save certain frames here…
while others appear to be salvageable with multiple adjustments to cookie3 jitter.
However adjusting a frame that looks fine in “cookie 2”,
but not in cookie3,
can sometimes be fixed by adjusting cookie2 jitter.
So maybe it looks fine in cookie2, but really there are visually undetectable problems…
or maybe just closer inspection to see the problem is needed.
Either way, this jitter issue is has become more difficult,
because now in order to fix cookie3, you have to start playing around with other cookie sops jitter.
This is sad because there were some very promising results prior to cookie3…
even though it's only on spheres in this example.
Perhaps we're back to your original condition:
“ only ever intersect two pieces at a time (ie. one piece per input) ”
Which would be unfortunate.
I'll give it some more time, after I get some sleep.
With these experiments
I now feel like we're getting really close to nailing this one.
I know from past post that others were very horny for this as well,
but it was never resolved.
I think we're getting close here.
thanks
and again… nicely done.
Jim
Your use of the “connectivity” sop and “primitive split” sop was nicely done.
The “connectivity” (created “class” attribute) will certainly make grouping a lot easier as well.
I just had the point colors just thrown in there for display purposes.
As far as rendering out the .bgeo files…
you're right, it doesn't make any difference.
Perhaps it was my constant tweaking evoking imaginative distortion. ops:
My attempts with subdivision was just a quick dirty means at trying to smooth out the geometry from the “consolidate edges” in the cookie.
Your solution of the “Primitive split” seems also to take care of the rough edges created by the “consolidate edges” of the “cookie”.
I've added a new version of the file.
All new sops have been colored light purple.
There is a “switch” near the bottom of the chain to move between the stable version (Switch setting 0) of the scene,
and another version (Switch setting 1) with a new problems.
Switch 0:
I added another stationary sphere (non-intersecting for a total of 2 spheres) into a “merge”.
The merge is then wired into the first input of cookie1.
The second input of cookie1 is the same as before, 5 animated non-intersecting spheres.
So now both inputs have multiple non-intersecting objects in them.
I thought I had the makings of a “rule” here with working with animated cookies.
You can have as many sources placed into a “merge” for either input,
as long as sources inside a merge do not intersect.
Even with consolidated edges,
you still need to avoid having the source geometry of the merge “intersect” in any way.
Then I complicated things, and this rule started to break down.
Switch 1:
This takes the output of cookie2, creates two copies of it.
One copy is rotated, scaled and translated, so it sits slightly above and in front of the original copy.
A new cookies is pulled (cookie3) as an “A minus B”.
It immediately appears that no amount of “jitter” (on cookie3) can save certain frames here…
while others appear to be salvageable with multiple adjustments to cookie3 jitter.
However adjusting a frame that looks fine in “cookie 2”,
but not in cookie3,
can sometimes be fixed by adjusting cookie2 jitter.
So maybe it looks fine in cookie2, but really there are visually undetectable problems…
or maybe just closer inspection to see the problem is needed.
Either way, this jitter issue is has become more difficult,
because now in order to fix cookie3, you have to start playing around with other cookie sops jitter.
This is sad because there were some very promising results prior to cookie3…
even though it's only on spheres in this example.
Perhaps we're back to your original condition:
“ only ever intersect two pieces at a time (ie. one piece per input) ”
Which would be unfortunate.
I'll give it some more time, after I get some sleep.
With these experiments
I now feel like we're getting really close to nailing this one.
I know from past post that others were very horny for this as well,
but it was never resolved.
I think we're getting close here.
thanks
and again… nicely done.
Jim
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
here's a hip file where I was screwing around with this.
I actually got it working exceptionally well!
There is a bit of a trick.
You'll need to render out your own “.bgeo” files (in the “rop_geometry”/rop output driver), and then place the proper path in the “file” sops in order to get this to work.
I've attached a .hip file, but let me break down what I found out.
Cookie 1: Large sphere as input 1. Multiple spheres that animate (but must never intersect each other), ran into a merge. Cookie is pulled as “A minus B”. “Jitter” is set once, with no keyframing! The normals even seem to be happy.
Cookie 2: Here I want to geometry to intersect with the holes in Cookie 1.
If I just do it off the last cookie (cookie 1) it seems to be unstable. If I render out the .Bgeo files for cookie1, and then read them back in as a “File” sop to input one of “Cookie 2” then things are quite stable.
This technique is repeated with a “torus” for cookie 3.
It takes rendering out .bgeo files (oh well),
but this is no longer such a big deal because a “merge” sop can be used as the second input of a cookie,
as long as the geometry going into the 2nd input never intesects with each other. Intersection might not be such a problem if the cookie was not animated
Jim
I actually got it working exceptionally well!
There is a bit of a trick.
You'll need to render out your own “.bgeo” files (in the “rop_geometry”/rop output driver), and then place the proper path in the “file” sops in order to get this to work.
I've attached a .hip file, but let me break down what I found out.
Cookie 1: Large sphere as input 1. Multiple spheres that animate (but must never intersect each other), ran into a merge. Cookie is pulled as “A minus B”. “Jitter” is set once, with no keyframing! The normals even seem to be happy.
Cookie 2: Here I want to geometry to intersect with the holes in Cookie 1.
If I just do it off the last cookie (cookie 1) it seems to be unstable. If I render out the .Bgeo files for cookie1, and then read them back in as a “File” sop to input one of “Cookie 2” then things are quite stable.
This technique is repeated with a “torus” for cookie 3.
It takes rendering out .bgeo files (oh well),
but this is no longer such a big deal because a “merge” sop can be used as the second input of a cookie,
as long as the geometry going into the 2nd input never intesects with each other. Intersection might not be such a problem if the cookie was not animated
Jim
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
Hey Edward
thanks for the link to the Hip file.
I'm eager to check it out at length,
and will comment on it.
It'll take a bit of time to deconstruct this,
but I will.
As far as the “consolidate edges” is concerned:
I find that it really tends to messy up the edge of the connecting surfaces.
To fix this I tried these options:
1)In OBJ in “Render” tab
Geometryolygons as subdivision surfaces
This helped some, but still pretty rough.
2) Also tried subdividing in sops,
same result just one happens at render and one happens in sops.
If I dig around perhaps I can come up with a solution for this problem (hopefully in sops)
thanks again
Jim
thanks for the link to the Hip file.
I'm eager to check it out at length,
and will comment on it.
It'll take a bit of time to deconstruct this,
but I will.
As far as the “consolidate edges” is concerned:
I find that it really tends to messy up the edge of the connecting surfaces.
To fix this I tried these options:
1)In OBJ in “Render” tab
Geometryolygons as subdivision surfaces
This helped some, but still pretty rough.
2) Also tried subdividing in sops,
same result just one happens at render and one happens in sops.
If I dig around perhaps I can come up with a solution for this problem (hopefully in sops)
thanks again
Jim
Technical Discussion » Animated "Cookie"
- Jim Ellis 2001
- 60 posts
- Offline
Hello all,
I know this topic was covered before at one point,
but I thought I'd try again.
I think animating geometry and recursively running it through the “Cookie” sop is about as cool as it gets.
There are a few lingering problems though that I can't seem to get around.
I thought I'd pick the accumulative brain of the forum, offer up my ideas, and see if there isn't a way to make this coolest tool work properly (when animated) for production purposes.
The scenario so far:
3 spheres same amount of points (frequency 6), animated translation, different scale. Three cookies total.
“Sphere 1” stationary, while “sphere 2” bashes into it with animation and a cookie is pulled as a “A minus B”, so “Sphere 1” gets a hole cut in it.
“Do Jitter” is set on the “Cookie”.
From here a “Clean” sop is used to help the normals and polys be legit.
Down the chain, “Sphere 3” is introduced and animated-bashes into the first cookie.
The 2nd cookie is also set to “A minus B”, with “do jitter”.
A “Clean” is used afterwards as well.
ok here are the problems.
1) I would have thought that the “Clean” sop would have taken care of any occurrences of reversed normals on the cookies, but it doesn't. There are frames here and there where the intersecting surfaces created still have inverted normals.
2) Even with “Jitter” on or off, there are moments where the surface does not calculate properly. In fact there are frames where the geometry disappears altogether.
ok here are some solutions I've come up with.
1) Render out the first “Cookie” as .bgeo, bring that in as a “File” sop. Then pull the next cookie.
This tends to make things more stable, but still not ideal surface wise.
That and the “Preceduralism” and creative interaction is destroyed.
2) Get everything working and then on a frame by frame basis animate the “Jitter amount” starting from the top of the chain. Huge pain in the butt.
Any ideas?
Is this just a matter of the limitation of the tool?
Basically… am I just asking too much from this tool?
Even worse problems when doing it on Nurbs with the “Surfsect” sop.
thanks
All my best
Jim
I know this topic was covered before at one point,
but I thought I'd try again.
I think animating geometry and recursively running it through the “Cookie” sop is about as cool as it gets.
There are a few lingering problems though that I can't seem to get around.
I thought I'd pick the accumulative brain of the forum, offer up my ideas, and see if there isn't a way to make this coolest tool work properly (when animated) for production purposes.
The scenario so far:
3 spheres same amount of points (frequency 6), animated translation, different scale. Three cookies total.
“Sphere 1” stationary, while “sphere 2” bashes into it with animation and a cookie is pulled as a “A minus B”, so “Sphere 1” gets a hole cut in it.
“Do Jitter” is set on the “Cookie”.
From here a “Clean” sop is used to help the normals and polys be legit.
Down the chain, “Sphere 3” is introduced and animated-bashes into the first cookie.
The 2nd cookie is also set to “A minus B”, with “do jitter”.
A “Clean” is used afterwards as well.
ok here are the problems.
1) I would have thought that the “Clean” sop would have taken care of any occurrences of reversed normals on the cookies, but it doesn't. There are frames here and there where the intersecting surfaces created still have inverted normals.
2) Even with “Jitter” on or off, there are moments where the surface does not calculate properly. In fact there are frames where the geometry disappears altogether.
ok here are some solutions I've come up with.
1) Render out the first “Cookie” as .bgeo, bring that in as a “File” sop. Then pull the next cookie.
This tends to make things more stable, but still not ideal surface wise.
That and the “Preceduralism” and creative interaction is destroyed.
2) Get everything working and then on a frame by frame basis animate the “Jitter amount” starting from the top of the chain. Huge pain in the butt.
Any ideas?
Is this just a matter of the limitation of the tool?
Basically… am I just asking too much from this tool?
Even worse problems when doing it on Nurbs with the “Surfsect” sop.
thanks
All my best
Jim
Technical Discussion » attribute remove?
- Jim Ellis 2001
- 60 posts
- Offline
Technical Discussion » attribute remove?
- Jim Ellis 2001
- 60 posts
- Offline
Hello all,
Does anyone know how to remove an attribute on specific points?
I set up the simplest scenario where a sphere has points that are grouped by “bound/enable”.
In other words, another object is translating through the top of a sphere,
the intersection then is grouped.
Those grouped points are run into a “point sop”, and color is added.
The “point sop” only adds the color I selected to the designated points in the group…
which is great.
The problem is that also adds a 1, 1, 1 value for all other points not in the group.
I don't want those other points to have color/Cd values.
So what I would wish for is an “Attribute Delete” sop,
that could remove the Cd attribute from the points that aren't in the group.
My hope is that those points “not in the group” could then just be affected by the shader diffuse values… or maybe grouped and used in another shader.
Perhaps the solution is in clever grouping,
but I'm not having any luck.
Any ideas?
Just as a side note:
There is something interesting that is happening here.
Any alteration in the Shaders Diffuse…
shows up (pretty much) as I intended in the Houdini modeling Viewport/open-gl-preview.
So the grouped points have a current bounding box for the color,
and the shader is set to be 7 in diffuse red.
The 7 red and Bounding Box are affecting each other in the viewport,
but not in the render.
huummmmm… clues.
thanks
Jim
Does anyone know how to remove an attribute on specific points?
I set up the simplest scenario where a sphere has points that are grouped by “bound/enable”.
In other words, another object is translating through the top of a sphere,
the intersection then is grouped.
Those grouped points are run into a “point sop”, and color is added.
The “point sop” only adds the color I selected to the designated points in the group…
which is great.
The problem is that also adds a 1, 1, 1 value for all other points not in the group.
I don't want those other points to have color/Cd values.
So what I would wish for is an “Attribute Delete” sop,
that could remove the Cd attribute from the points that aren't in the group.
My hope is that those points “not in the group” could then just be affected by the shader diffuse values… or maybe grouped and used in another shader.
Perhaps the solution is in clever grouping,
but I'm not having any luck.
Any ideas?
Just as a side note:
There is something interesting that is happening here.
Any alteration in the Shaders Diffuse…
shows up (pretty much) as I intended in the Houdini modeling Viewport/open-gl-preview.
So the grouped points have a current bounding box for the color,
and the shader is set to be 7 in diffuse red.
The 7 red and Bounding Box are affecting each other in the viewport,
but not in the render.
huummmmm… clues.
thanks
Jim
Technical Discussion » Create New Vop Type
- Jim Ellis 2001
- 60 posts
- Offline
ok I just tried it without renaming any of the ops or their parmater labels/names.
The same problem.
So it appears to NOT be a naming convention.
The same problem.
So it appears to NOT be a naming convention.
Technical Discussion » Create New Vop Type
- Jim Ellis 2001
- 60 posts
- Offline
Yeah I get this one as well.
I'm not sure why it actually happens.
My guess is that the compiler doesn't like some bit of code (or naming convention) in the Vop network.
here is my last error message in attempting this:
<unknown> Error(-1): Expecting close brace for block
<unknown> Error(-1): script unknown identifier x1 = x + fwidth;
I've run into this problem many times before with trying to “create new Vop types from a vop network”.
I can't remeber exactly what my previous error message were exactly,
but I know they all contained the “expecting close brace”.
Anyone out there know how to get around this?
thanks
Jim
I'm not sure why it actually happens.
My guess is that the compiler doesn't like some bit of code (or naming convention) in the Vop network.
here is my last error message in attempting this:
<unknown> Error(-1): Expecting close brace for block
<unknown> Error(-1): script unknown identifier x1 = x + fwidth;
I've run into this problem many times before with trying to “create new Vop types from a vop network”.
I can't remeber exactly what my previous error message were exactly,
but I know they all contained the “expecting close brace”.
Anyone out there know how to get around this?
thanks
Jim
Technical Discussion » Hud-slider locked to integers?
- Jim Ellis 2001
- 60 posts
- Offline
Technical Discussion » Muscle primitive?
- Jim Ellis 2001
- 60 posts
- Offline
I HAVE NOT TRIED THE SCENE…
BUT DO YOU HAVE “CAPS LOCK” ACTIVATED ON YOUR KEYBOARD?
I've been fudged by this one before.
If it's not that… sorry I mentioned it :wink:
It looks as if you've been working in Houdini for a while (over 300 forum posts), so that is most likely not it.
BUT DO YOU HAVE “CAPS LOCK” ACTIVATED ON YOUR KEYBOARD?
I've been fudged by this one before.
If it's not that… sorry I mentioned it :wink:
It looks as if you've been working in Houdini for a while (over 300 forum posts), so that is most likely not it.
Technical Discussion » dops tutorial (dynamics quickstart) small issue "cloth&
- Jim Ellis 2001
- 60 posts
- Offline
Hi all,
While doing the DOPs-tutorial/Dynamics-quickstart
(vase, table, ball, and cloth) I got stuck on something.
Eventually I figured it out, but thought I should mention it because I couldn't find a post where anyone mentioned it.
When doing the “cloth dynamics” part of the tutorial,
in order to get the cloth simulation to run properly,
the objects must run into the “Merge” Dop in the proper order.
The last item to be merged is must be the “Cloth Solver” Dop.
I didn't think it really mattered (as I've never run into this problem in sops),
but my cloth simulation won't work until I corrected this.
Jim
While doing the DOPs-tutorial/Dynamics-quickstart
(vase, table, ball, and cloth) I got stuck on something.
Eventually I figured it out, but thought I should mention it because I couldn't find a post where anyone mentioned it.
When doing the “cloth dynamics” part of the tutorial,
in order to get the cloth simulation to run properly,
the objects must run into the “Merge” Dop in the proper order.
The last item to be merged is must be the “Cloth Solver” Dop.
I didn't think it really mattered (as I've never run into this problem in sops),
but my cloth simulation won't work until I corrected this.
Jim
Technical Discussion » Cameras that can see other camera's output (am I nuts)
- Jim Ellis 2001
- 60 posts
- Offline
:roll: :wink: :idea:
yeah… something like that.
I'll show you once I really get it going
if you're down.
yeah… something like that.
I'll show you once I really get it going
if you're down.
Technical Discussion » Cameras that can see other camera's output (am I nuts)
- Jim Ellis 2001
- 60 posts
- Offline
Thanks to everyone for the ideas, clues, and solutions!
Simon your response was crucial in me getting what I was after!
I nailed the first steps because of your assistance.
Now I can continue on.
Thanks again guys!
all my best
Jim
Simon your response was crucial in me getting what I was after!
I nailed the first steps because of your assistance.
Now I can continue on.
Thanks again guys!
all my best
Jim
Edited by - April 17, 2006 18:39:02
Technical Discussion » Cameras that can see other camera's output (am I nuts)
- Jim Ellis 2001
- 60 posts
- Offline
Edward… as always your suggestions are great!
I “edited” my post to explain why this would not work.
Mind you I am a self-proclaimed novice.
That said I do my best to help other “of my kind” with long drawn out explainations.
I don't think your solution will work given what I've re-written in this post.
Mind you I am such a novice that I have yet to figure out (with the latest version of Houdini) how to even get Cop info into a Shop.
thanks
Jim
I “edited” my post to explain why this would not work.
Mind you I am a self-proclaimed novice.
That said I do my best to help other “of my kind” with long drawn out explainations.
I don't think your solution will work given what I've re-written in this post.
Mind you I am such a novice that I have yet to figure out (with the latest version of Houdini) how to even get Cop info into a Shop.
thanks
Jim
Edited by - April 17, 2006 18:38:14
Technical Discussion » Cameras that can see other camera's output (am I nuts)
- Jim Ellis 2001
- 60 posts
- Offline
okay this is another weird one
heres what I want to do:
1) a single camera (first camera) pointed at some animation of geometry. Let's say a sphere moving up and down.
2) Take what the first camera is seeing and import into it into Cops.
3) Take that Cop information and feed into the texture parameter of a shop. So the shop doesn't get its info from a “file texture”, but instead gets it from the first camera. This way the camera is used as a “texture generator”.
THIS IS WHAT I“M AFTER. A camera that can generate textures (and be altered in Cops) that can be applied in Shops. Doing this as a post-render effect WILL NOT WORK.
4) Then I will set up a second camera that can only see a new 3D object (let's say a cube) with the first camera's ”viewing information“ input mapped onto it as a material/texture. I imagine the second camera will need to run $F-1 to make this work… so I have to be able to set up the second camera to read information a frame later. THIS IS ACTUALLY VERY CRUCIAL FOR WHAT I'M AFTER. A camera with a one frame delay. Like a animatable ”Cache“ value for the ”second camera“.
so there are a few issues here
a) getting the cameras ”view“ information into Cops.
b) Exporting that color/texure information from cops into a Shop.
c) Setting up a secondary camera that is capable of a $F-1 lag.
This will allow the ”secondary camera" to see what is mapped on a 3D object (from the first camera) at a one frame lag.
I am nuts
I have my reasons
Anyone care to help?
Freaks welcome!
thanks for the time
Jim
heres what I want to do:
1) a single camera (first camera) pointed at some animation of geometry. Let's say a sphere moving up and down.
2) Take what the first camera is seeing and import into it into Cops.
3) Take that Cop information and feed into the texture parameter of a shop. So the shop doesn't get its info from a “file texture”, but instead gets it from the first camera. This way the camera is used as a “texture generator”.
THIS IS WHAT I“M AFTER. A camera that can generate textures (and be altered in Cops) that can be applied in Shops. Doing this as a post-render effect WILL NOT WORK.
4) Then I will set up a second camera that can only see a new 3D object (let's say a cube) with the first camera's ”viewing information“ input mapped onto it as a material/texture. I imagine the second camera will need to run $F-1 to make this work… so I have to be able to set up the second camera to read information a frame later. THIS IS ACTUALLY VERY CRUCIAL FOR WHAT I'M AFTER. A camera with a one frame delay. Like a animatable ”Cache“ value for the ”second camera“.
so there are a few issues here
a) getting the cameras ”view“ information into Cops.
b) Exporting that color/texure information from cops into a Shop.
c) Setting up a secondary camera that is capable of a $F-1 lag.
This will allow the ”secondary camera" to see what is mapped on a 3D object (from the first camera) at a one frame lag.
I am nuts
I have my reasons
Anyone care to help?
Freaks welcome!
thanks for the time
Jim
Edited by - March 29, 2006 00:06:03
-
- Quick Links